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(54) Method and apparatus for providing proxylng and transcoding of documents In a distributed 
metworfc 

(57) A method of providing a document to a client 
coupled to a server is provided. The server provides a 
number of Internet services to the client, including func- 
tioning as a caching proxy on behalf of the client for pur- 
poses of accessing the World Wide Web. The proxying 
server includes a persistent document database, which 
stores various attributes of all documents previously 
retrieved in response to a request from a client. When a 
Web document is retrieved from a remote server in 
response to a request from the client, the database is 
consulted and the stored information relating to the 
requested document is used by the server in transcod- 
ing the document The document is transcoded for vari- 
ous purposes, including to circumvent bugs or quirks 
found in the document to size the document for display 
on a television set, to improve transmission efficiency of 
the document and to reduce latency. The transcoder 
makes use of the document database to perform these 
functions. The document database is also used for 
prefetching previously requested documents and 
images and for reducing latency when downloading " ~ 

images to the client FIG 1 
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Figure 2 illustrates a client according to the present 
invention. 

Figure 3 is a block diagram of a server according to 
the present invention. 

Figure 4A illustrates a server including a proxy s 
cache and a transcoder. 

Figure 4B illustrates databases used in a server 



I. System Overview u 

The present invention is included in a system, 
known as WebTV™, for providing a user with access to 
the Internet. A user of a WebTV™ client generaly 
accesses a WebTV™ server via a direct-dial telephone 
(POTS, for "plain old telephone service"), ISDN (Inte- 



according to the present invention. 
Figure 5 is a flow diagram illustrating a routine for 
transcoding a document retrieved from a remote io 
server using data stored in a persistent database. 
Figure 6 is a flow diagram illustrating a routine for 
transcoding an HTML document for purposes of 
eliminating bugs or undesirable features. 
Figure 7 is a flow diagram illustrating a routine for is 
reducing latency when downloading a document 
referencing an image to a client 
Figure 8 is a flow diagram illustrating a routine for 
updating documents stored in the proxy cache 
using data stored in a persistent database. 20 
Figure 9 is a flow diagram illustrating a routine used 
by a server for retrieving documents from another 
remote server. 

Figure 10 is a block diagram of a prior art server 
system showing a relationship between various 2$ 
services and a database. 

Figure 1 1 is a block diagram of a. server system 
according to the present invention showing a rela- 
tionship between various services and a user data- 
base, so 
Figure 12 is a flow diagram illustrating a routine 
used by a server for regulating access to various 
services provided by the server. 



DETAILED DE SCRIPTION 



35 



A method and apparatus are described for provid- 
ing proxying and transcoding of documents in a net- 
work. In the following description, for purposes of 
explanation, numerous specific details are set forth in 40 
order to provide a thorough understanding of the 
present invention. It will be evident, however, to one 
skilled in the art that the present invention may be prac- 
ticed without these specific details. In other instances, 
well-known structures and devices are shown in block 45 
diagram form in order to avoid unnecessarily obscuring 
the present invention. 

The present invention includes various steps, which 
will be described below. The steps can be embodied in 
machine-executable instructions, which can be used to so 
cause a general-purpose or special-purpose processor 
programmed with the instructions to perform the steps. 
Alternatively, the steps of the present invention might be 
performed by specific hardware components that con- 
tain hardwired logic for performing the steps, or by any ss 
combination of programmed computer components and 
custom hardware components. 



grated Services Digital Network), or other similar con- 
nection, in order to browse the Web, send and receive 
electronic mail (e-mail), and use various other WebTV™ 
network services. The WebTV™ network services are 
provided by WebTV™ servers using software residing 
within the WebTV™ servers in conjunction with software 
residing within a WebTV™ client 

Figure 1 illustrates a basic configuration of the 
WebTV™ network according to one embodiment. A 
number of WebTV™ clients 1 are coupled to a modem 
pool 2 via direct-dial, bi-directional data connections 29, 
which may be telephone (POTS, i.e., "plain old tele- 
phone service"), ISDN (Integrated Services Digital Net- 
work), or any other similar type of connection. The 
modem pool 2 is coupled typically through a router, 
such as that conventionally known in the art, to a 
number of remote servers 4 via a conventional network 
infrastructure 3, such as the Internet The WebTV™ sys- 
tem also includes a WebTV™ server 5. which specifi- 
cally supports the WebTV™ clients 1. The WebTV™ 
clients 1 each have a connection to the WebTV™ server 
5 either directly or through the modem pool 2 and the 
Internet 3. Note that the modem pool 2 is a conventional 
modem pool, such as those found today throughout the 
world providing access to the Internet and private net- 
works. 

Note that in this description, in order to facilitate 
explanation the WebTV™ server 5 is generally dis- 
cussed as if it were a single device, and functions pro- 
vided by the WebTV™ services are generally discussed 
as being performed by such single device. However, the 
WebTV™ server 5 may actually comprise multiple phys- 
ical and logical devices connected in a distributed archi- 
tecture, and the various functions discussed below 
which are provided by the WebTV™ services may actu- 
ally be distributed among multiple WebTV™ server 
devices. 

II. Client System 

Figure 2 illustrates a WebTV™ client 1. The 
WebTV™ client 1 includes an electronics unit 10 (here- 
inafter referred to as "the WebTV™ box 1 0"), an ordinary 
television set 12, and a remote control 1 1 . In an alterna- 
tive embodiment of the present invention, the WebTV™ 
box 10 is built into the television set 12 as an integral 
unit The WebTV™ box 10 includes hardware and soft- 
ware for providing the user with a graphical user inter- 
face, by which the user can access the WebTV™ 
network services, browse the Web, send e-mail, and 
otherwise access the Internet 

The WebTV™ client 1 uses the television set 12 as 
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ical and diagnostic information for every Web page that 
is accessed at any time by a WebTV™ client 1 . As is well 
known, a Web page may correspond to a document 
written in a language such as HTML (Hypertext Mark- 
Up Language), VRML (Virtual Reality Modelling Lan- 5 
guage), or another suitable language. Alternatively, a 
Web page may represent an image, or a document 
which references one or more images. According to the 
present invention, once a document or image is 
retrieved by the WebTV™ server 5 from a remote server 10 
4 for the first time, detailed information on this document 
or image is stored permanently in the document data- 
base 61. More specifically, for every Web page that is 
retrieved from a remote server 4, any or all of the follow- 
ing data are stored in the document database 61 : 15 

1) information identifying bugs (errors) or quirks in 
the Web page, or undesirable effects caused when 
the Web page is displayed by a client 1 ; 

2) relevant bug-finding algorithms; so 

3) the date and time the Web page was last 
retrieved; 

4) the date and time the Web page was most 
recently altered by the author; 

5) a checksum for determining whether the Web 2s 
page has been altered; 

6) the size of the Web page (in terms of memory): 

7) the type of Web page (e.g., HTML document 
image, etc.); 

8) a list of hypertext anchors (links) in the Web page 30 
and corresponding URLs; 

9) a list of the most popular anchors based on the 
number of "hits" (requests from a client 1); 

10) a list of related Web pages which can be 
prefetched 35 

11) whether the Web page has been redirected to 
another remote server 4; 

12) a redirect address (if appropriate); 

13) whether the redirect (if any) is temporary or per- 
manent and rf permanent, the duration of the redt- 40 
rect 

14) if the Web page is an image, the size of the 
image in terms of both physical dimensions and 
memory space; 

15) the sizes of in-line images (images displayed in 45 
text) referenced by the document defining the Web 
page; 

16) the size of the largest image referenced by the 
document; 

17) information identifying any image maps in the so 
Web page; 

18) whether to resize any images corresponding to 
the Web page; 

19) an indication of any forms or tables in the Web 
page; 55 

20) any unknown protocols; 

21) any links to "dead" Web pages (i.e., pages 
which are no longer active); 

22) the latency and throughput of the remote server 



4 on which the Web page is located; 

23) the character set of the document; 

24) the vendor of the remote server 4 on which the 
Web page is located; 

25) the geographic location of the remote server 4 
on which the Web page is located; 

26) the number of other Web pages which refer- 
ence the subject Web page; 

27) the compression algorithm used by the image 
or document; 

28) the compression algorithm chosen by the trans- 
coder; 

29) a value indicating the popularity of the Web 
page based on the number of hits by clients; and 

30) a value indicating the popularity of other Web 
pages which reference the subject Web page. 

B. Transcoding 

As mentioned above, the WebTV™ services pro- 
vide a transcoder 66, which is used to rewrite certain 
portions of the code in an HTML document for various 
purposes. These purposes include: (1) correcting bugs 
in documents; (2) correcting undesirable effects which 
occur when a document is displayed by the client 1 ; (3) 
improving the efficiency of transmission of documents 
from the server 5 to the client 1 ; (4) matching hardware 
decompression technology within the client 1 ; (5) resiz- 
ing images to fit on the television set 12; (6) converting 
documents into other formats to provide compatibility; 
(7) reducing latency experienced by a client 1 when dis- 
playing a Web page with in-line images (images dis- 
played in text); and, (8) altering documents to fit into 
smaller memory spaces. 

There are three transcoding modes used by the 
transcoder 66: (1) streaming, (2) buffered, and (3) 
deferred. Streaming transcoding refers to the transcod- 
ing of documents on a line-by-line basis as they are 
retrieved from a remote server 4 and downloaded to the 
client 1 (i.e., transcoding "on the fly*). Some documents, 
however, must first be buffered in the WebTV™ server 5 
before transcoding and downloading them to the client 
1 . A document may need to be buffered before transmit- 
ting it to the client 1 if the type of changes to be made 
can only be made after the entire document has been 
retrieved from the remote server 4. Because the proc- 
ess of retrieving and downloading a document to the cli- 
ent 1 increases latency and decreases throughput it is 
not desirable to buffer all documents. Therefore, the 
transcoder 66 accesses and uses information in the 
document database 61 relating to the requested docu- 
ment to first determine whether a requested document 
must be buffered for purposes of transcoding, before 
the document is retrieved from the remote server 4. 

In the deferred mode, transcoding is deferred until 
after a requested document has been downloaded to a 
client 1. The deferred mode therefore reduces latency 
experienced by the client 1 in receiving the document. 
Transcoding may be performed immediately after down- 
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quantified based upon the number of hits for that docu- 
ment which is tracked in the document database 61. 
For example, it might be prudent to simply assign a rel- 
atively short period of validity to a document which is 
very popular and a longer period of validity to a docu- 
ment which is less popular. 

Another alternative basis for the validity of a docu- 
ment is the observed rate of change of the document 
Again, data in the persistent document database 61 can 
be used. That is, because the document database 61 
stores the date and time on which the document was 
last observed to change, the server 5 can approximate 
how often the document actually changes. A document 
or image which is observed to change frequently (e.g., 
a weather map or a news page) can be assigned a rel- 
atively short period of validity. It will be recognized that 
numerous other ways of determining validity are possi- 
ble. 

2. Transcoding to Reduce Latency 

Another purpose for transcoding is to allow docu- 
ments requested by a client 1 to be displayed by the cli- 
ent 1 more rapidly. Many HTML documents contain 
references to "in-line" images, or images that will be dis- 
played in text in a Web page. The normal process used 
in the prior art to display a Web page having in-line 
images is that the HTML document referencing the 
image is first downloaded to the client followed by the 
client's requesting the referenced image. The refer- 
enced image is then retrieved from the remote server on 
which it is located and downloaded to the client One 
problem associated with the prior art however, is that 
the speed with which a complete Web page can be dis- 
played to the user is often limited by the time it takes to 
retrieve in-line images. One reason for this is that it sim- 
ply takes time to retrieve the image itself after the refer- 
encing document has been retrieved. Another reason is 
that, in the prior art, if the referencing document does 
not specify the size of the image, the Web page gener- 
ally cannot be displayed until the image itself has been 
retrieved. The present invention overcomes these limi- 
tations. 

According to the present invention, information 
stored in the document database 61 regarding the in- 
line images is used to transcode the referencing docu- 
ment in order to reduce latency in displaying the Web 
page Once any document which references an in-line 
image is initially retrieved by the server 5, the fact that 
the document references an in-line image is stored in 
the document database 61. In addition, the size of the 
image is determined, either from the document (if spec- 
ified) or from the image itself, and then stored in the 
document database 61. Consequently, for documents 
which do not specify the size of their in-line images, the 
size information stored in the database 61 is then used 
the next time the document is requested in order to 
reduce latency in downloading and displaying the Web 
page 



Refer now to Figure 7, which illustrates a routine for 
reducing latency when downloading a document refer- 
encing an image to a client 1. Assume that a client 1 
sends a request to the server 5 for an HTML document 

5 containing a reference to an in-line image. Assume fur- 
ther that the size of the image is not specified in the doc- 
ument itself. Initially, the server 5 determines whether 
that document has been previously retrieved (step 701). 
If not the standard initial retrieval and transcoding pro- 

io cedure is followed (step 706), as described in connec- 
tion with Figure 6. If, however, the document has been 
previously retrieved, then the transcoder 66 accesses 
the size information stored in the document database 
61 for the in-line image (step 702). Based on this size 

15 information, the HTML document is transcoded such 
that when the Web page is initially displayed by the cli- 
ent 1, the area in which the image belongs is replaced 
by a blank region enveloping the shape of the image. 
Thus, any in-line image referenced by a document is 

so displayed initially as a blank region. Consequently, the 
client 1 can immediately display the Web page corre- 
sponding to the HTML document even before the refer- 
enced image has been retrieved or downloaded (i.e., 
even before the size of the image is known to the client 

26 D. 

As the transcoded HTML document is downloaded 
to the client, the image is retrieved from the appropriate 
remote server 4 (step 704). Once the image is retrieved 
from the remote server 4 and downloaded to the client 
30 1 , the client 1 replaces the blank area in the Web page 
with the actual image (step 705). 

3. Transcoding to Display Web Pages on a Television 

35 As noted above, the client 1 utilizes an ordinary tel- 
evision set 12 as a display device. However, images in 
Web pages are generally formatted for display on a 
computer monitor, not a television set. Consequently, 
the transcoding function of the present invention is used 
40 to resize images for display on the television set 1 2. This 
includes reseating images as necessary to avoid trunca- 
tion when displayed on the television set 12. 

ft should be noted that prior art Web browsers 
which operate on computer monitors typically use resiz- 
es able windows. Hence, the size of the visible region var- 
ies from client to client However, because the web 
browser used by the WebTV™ client 1 is specrficaly 
designed for display on a television set the present 
invention allows documents and images to be formatted 
so when they are cached. 

4. Transcoding for Transmission Efficiency 

Documents retrieved by the server 5 are also trans- 
55 coded to improve transmission efficiency. In particular, 
documents can be transcoded in order to reduce high 
frequency components in order to reduce interlace 
flicker when they are displayed on a television set 

Documents can also be transcoded in order to 
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5 to inform the client 1 of documents or images which 
are popular to allow the client 1 to perform the prefetch- 
ing. In particular, for any given document, a list is main- 
tained in the server 5 of the most popular hypertext 
anchors in that document (i.e., those which have previ- 
ously received a large number of hits). When that docu- 
ment is requested by the client 1, the server 5 provides 
the client 1 with an indication of these popular links. 

3. Redirects 

Web pages are sometimes forwarded from the 
remote server on which they are initially placed to a dif- 
ferent location. Under the HTTP (Hypertext Transport 
Protocol), such forwarding is sometimes referred to as a 
"redirect." When an HTML document is initially stored 
on one remote server and then later transferred to 
another remote server, the first remote server will pro- 
vide, in response to a request for that document cm 
indication that the document has been transferred to a 
new remote server. This indication generally includes a 
forwarding address ("redirect address"), which is gener- 
ally a URL 

In the prior art, when a computer requesting a Web 
page receives a redirect, H must then submit a new 
request to the redirect address. Having to submit a sec- 
ond request and wait for a second response consumes 
time and increases overall latency. Consequently, the 
present invention uses the document database 61 to 
store any redirect address for each document or image. 
Any time a redirected document is requested, the server 
5 automatically accesses the redirect address to 
retrieve the document The document or image is pro- 
vided to the client 1 based on only a single request from 
the client 1. The change in location of the redirected 
document or image remains completely transparent to 
the client 1. 

Figure 9 illustrates a routine performed by the 
server 5 in accessing documents which may have been 
forwarded to a new remote server. Initially, the server 5 
receives a request for a document which generally 
includes an address (step 901). The server 5 then 
accesses the document database 65 to determine 
whether there is a redirect address for the requested 
document (step 902). K there is no redirect address, 
then the server 5 accesses a remote server 4 based on 
the address provided in the document request from the 
client 1 (step 903). Assuming that the remote server 4 
does not respond to the server 5 with a redirect (step 
904), the document is retrieved and downloaded to the 
client 1 by the server 5 (step 907). If, however, a redirect 
address was stored in the document database 65 (step 
902), then the server 5 accesses the requested docu- 
ment according to the redirect address (step 906). Or, if 
the remote server 4 responded with a redirect (step 
904), then the server 5 saves the redirect address to the 
document database 61 (step 905) and accesses the 
requested document according to the redirect address 
(step 906). 



4. Other Proxy Functions 

The document database 65 also stores information 
relating to the performance of each remote server 4 

5 from which a document is retrieved. This information 
includes the latency and throughput of the remote 
server 4. Such information can be valuable in instances 
where a remote server 4 has a history of responding 
slowly. For example, when the document is requested, 

w this knowledge can be used by the server 5 to provide a 
predefined signal to the client 1. The client 1 can, in 
response to the signal, indicate to the user that a delay 
is likely and give the user the option of canceling the 
request. 

15 

5. Backoff Mode 

Although the server 5 generally operates in the 
proxy mode, it can also enter a "backoff mode" in which 

20 the server 5 does not act as a proxy, or the server 5 per- 
forms only certain aspects of the normal proxying func- 
tions. For example, if the proxy cache 65 is overloaded, 
then the server 5 can enter a backoff mode in which 
documents are not cached but are transcoded as 

25 required. Alternatively, during times when the server 5 is 
severely overloaded with network traffic, the server 5 
may instruct the client 1 to bypass the server 5 and con- 
tact remote servers 4 directly for a specified time or until 
further notice. Or, the server 5 can enter a flexible back- 

30 off mode in which the client 1 will be instructed to con- 
tact a remote server 4 directly only for certain Web sites 
for a limited period of time. 

D. Access to WebTV™ Services 

35 

The WebTV™ server 5 provides various services to 
the client 1 , such as proxying and electronic mail ("e- 
mail"). In the prior art, certain difficulties are associated 
with allowing a client computer access to different serv- 

40 ices of an Internet service, as will now be explained with 
reference to Figure 10. 

Figure 10 illustrates a client-server system accord- 
ing to one prior art embodiment The server 76 provides 
various services A, B, and C. The server 76 includes a 

45 database 71 for storing information on the user's access 
privileges to services A, B, and C. The client 75 of the 
embodiment of Figure 10 accesses any of services A, 
B, and C by contacting that service directly. The con- 
tacted service then accesses the database 71 , which 

so stores the access privileges of the client 75, to deter- 
mine whether the client 75 should be allowed to access 
that service. Hence, each service provided by the 
server 76 requires direct access to the database 71. 
This architecture results in a large number of accesses 

55 being made to the database 71 , which is undesirable. In 
addition, the fact that each service independently has 
access to the database 71 raises security concerns. 
Specifically, it can be difficult to isolate sensitive user 
information. The present invention overcomes such dif- 
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service. It should also be noted that separate service 
names can also refer to the same service. 

Assume, lor example, that the e-mail service pro- 
vided by the WebTV™ system is designated by the serv- 
ice name "WTV-mailta" A client 1 can access any s 
provider of this e-mail service using the same URL. The 
client 1 merely chooses the appropriate port number 
and IP number to distinguish between providers. If the 
client 1 is unable to connect to one e-mail provider, it 
can simply contact the next one in the fist. io 

Thus, at log-in time, a client 1 is provided with both 
a ticket containing privileges and capabilities as well as 
a list of service providers, as illustrated in Figure 12. Ini- 
tially, the log-in service 78 determines whether the user 
of client 1 is a valid user (step 1201). If not. log-in is is 
denied (step 1205). If the user is a valid user, then the 
log-in service 78 gathers user information from the user 
database 62 and generates a ticket 82 (step 1202). The 
log-in service 78 also generates the above-described 
list of services (step 1203). The ticket 82 and the list of so 
services are then downloaded to the client 1 (step 
1204). 

3. Asynchronous Notification to Clients by Server 

25 

Another limitation associated with prior art Internet 
servers is the inability to provide asynchronous notifica- 
tion information to the client in the absence of a request 
from the client to do so. It would be desirable, for exam- 
ple, for a server to notify a client on its own initiative so 
when a particular Web page has changed or that a par- 
ticular service is inaccessible. The server 5 of the 
present invention provides such capability, and the cli- 
ent 1 is configured to receive and decode such notifica- 
tions. For example, the client 1 can receive updates of 35 
its listing of service providers from the server 5 at vari- 
ous points in time, as already described. Similarly, if a 
particular service provider becomes unavailable, that 
fact will be automatically communicated to the client 1. 
As another example, if e-mail addressed to the user has 40 
been received by the server 5, then the server 5 will 
send a message to the client 1 indicating this fact. The 
client 1 will then notify the user that e-mail is waiting by 
a message displayed on the television set 12 or by an 
LED (light emitting diode) built into the housing of 45 
WebTV™ box 10. 

Thus, a method and apparatus have been 
described for providing proxying and transcoding of 
documents in a network. Although the present invention 
has been described with reference to specific exerrv so 
plary embodiments, it will be evident that various modi- 
fications and changes may be made to these 
embodiments without departing from the broader spirit 
and scope of the invention as set forth in the claims. 
Accordingly, the specification and drawings are to be 65 
regarded in an illustrative rather than a restrictive sense. 



Claims 

1. In a proxying server coupled to a client and to a 
remote server, the proxying server operating as a 
proxy on behalf of the client for accessing the 
remote server, a method of providing a first docu- 
ment to the client, the method comprising the steps 
of: 

retrieving the first document from the remote 
server in response to a request from the client, 
the document including data for causing the cli- 
ent to generate a display; 
using the proxying server to alter the data in the 
first document to form a transcoded document; 
and 

transmitting the transcoded document to the 
client 

2. A method according to claim 1 , wherein the step of 
using the proxying server to alter the data in the first 
document comprises the steps of: 

analyzing the data to determine whether a pre- 
determined condition is present in the data, 
wherein the predetermined condition com- 
prises data which, when used by the client, 
causes an error condition to occur; and 
if the predetermined condition is present in the 
data revising the data to eliminate the prede- 
termined condition. 

3. A method according to claim 1 , wherein the step of 
transmitting the transcoded document to the client 
is performed prior to performing the step of using 
the proxying server to alter the data in the first doc- 
ument 

4. A method according to claim 1, wherein the client 
includes a television display, wherein the document 
references an image, and wherein the step of using 
the proxying server to alter the data in the docu- 

. merit comprises the step of revising the data such 
that the image is sized for display on the television 
display. 

5. A method according to claim 1, further comprising 
the steps of: 

retrieving an image from the remote server in 
response to a request from the client, wherein 
the image has a first image format; and using 
the proxying server to convert the image from 
the first image format to a second image for- 
mat 

6. A method according to claim 1, wherein the first 
document includes a link to a second document, 
the link including a first address, and wherein the 
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using the second service to receive a second 
access request from the client, the second 
access request for requesting use of the sec- 
ond service by the client the second access 
request including a copy of the information 5 
packet; and 

using the copy of the information packet to reg- 
ulate access by the client to the second serv- 
ice 

10 

21 . A method according to claim 20, wherein the plural- 
ity of on-line services are Internet services. 

22. A method according to claim 20, wherein the sec- 
ond service is a proxy service by which the server is 
functions as a proxy on behalf of the client for pur- 
poses of accessing a second server. 

23. In server system coupled to a client a method of 
providing the client with a plurality of redundant 20 
services, each of the redundant services being sub- 
stantially equivalent to each of the other redundant 
services, the method comprising the steps of: 



providing the client with a service name appli- 25 
cable to all of the redundant services; 
providing the client with a unique port number 
for each service; 

providing the client with a unique protocol for 
each service; so 
receiving a request to access one of the redun- 
dant services from the client, the request 
including an address specifying the service 
name; and 

granting access to one of the redundant serv- 35 
ices in accordance with the name included in 
the address, one of the port numbers and one 
of the protocols, such that the client uses the 
same address to access any of the redundant 
services. 40 

24. A method accordng to claim 1, wherein the 
address is a URL (Uniform Resource Locator) 
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metwortc 

(57) A method of providing a document to a client 
coupled to a server is provided. The server provides a 
number of Internet services to the client, including func- 
tioning as a caching proxy on behalf of the client for pur- 
poses of accessing the World Wide Web. The proxying 
server includes a persistent document database, which 
stores various attributes of all documents previously 
retrieved in response to a request from a client. When a 
Web document is retrieved from a remote server in 
response to a request from the client, the database is 
consulted and the stored information relating to the 
requested document is used by the server in transcod- 
ing the document The document is transcoded for vari- 
ous purposes, including to circumvent bugs or quirks 
found in the document, to size the document for display 
on a television set, to improve transmission efficiency of 
the document and to reduce latency. The transcoder 
makes use of the document database to perform these 
functions. The document database is also used for 
prefetching previously requested documents and 
images and for reducing latency when downloading 
images to the client 
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